The Internet has become a resource of incredible power for many people. The ability to locate information on almost any subject, simply by using a computer, has made possible whole new avenues of research. Users can locate information on their subject of choice almost as simple as asking a question.
But language issues complicate the use of the Internet. Although English is currently the dominant language of the Internet, it is by no means the only language available. Content pages exist in just about every written language on the face of the planet.
Since few people can read every written language, different language versions of content pages can be provided. For example, a person who is comfortable communicating in English can view a content page written in English, whereas a Japanese native can view a content page prepared in Japanese.
The original way users specified the language in which they viewed material was by knowing the uniform resource locator (URL) of the content site written in that language. For example, if a site provided a content page in both English and Japanese formats, the user had to know the URL of the English content page to view the page in English, or the URL of the Japanese content page to view the page in Japanese.
FIG. 1 shows a prior art system for accessing information in a preferred language. In FIG. 1, a user is using computer system 105 to access network 110. Computer system 105 includes the standard components of a computer system: computer (including a processor, memory, etc.), monitor, keyboard, and mouse, but a person skilled in the art will recognize other variations that can be substituted for computer system 105 (e.g., a dumb terminal). Across network 110 is server 115, storing content page 120. When the user enters the URL of content page 120 into address field 125 of browser 130, the content page is shown in browser 130 (displayed on the monitor of computer system 105). Note that in FIG. 1, the user has entered http://www.website.com/webpage_EN.html as the content page. The use of ‘_EN’ as part of the URL lets the user know that the content page is written in English. If the user wanted to see the content page in Japanese, the user could enter http://www.website.com/webpage_JP.html instead (‘_JP’ specifying the Japanese-language version of the content page). (There is no required format for the names for content pages: these are merely exemplary.)
But there is a significant handicap to the approach of having the user specify by URL the preferred language for display in the browser. If the user does not know the correct URL, the user cannot see the material in the preferred language.
More recently, browsers have added the capability to specify a preferred language as a setting for the browser. The user then only needs to know the URL for the main content page. Processing the URL by the browser includes sending the preferred language to the web site (as shown by arrow 135). This information is included in the header of a packet sent from the browser to the web site. Then, it becomes the responsibility of the web site to process the header information, determine the preferred language, and display the content page in the preferred language (assuming the web site includes the content page in the preferred language).
But still problems remain. Problems lie in defining the user's preferred language. Although the user does not need to specify for each content page the preferred language for display of the content page, the user still has to set the browser up to know the preferred language. This requires a manual step by the user on his computer. Further, every time the user changes computers, the browser on the new computer must be configured to know the preferred language. Finally, if the user uses a computer that is not dedicated to him (for example, the user works on a locally public machine or on machines dedicated primarily to other users), changing the preferred language would affect other users, perhaps to their displeasure (if the other users prefer a different language).
Problems also exist in displaying content to the user in the desired language. The earlier-described technique of assembling a content page with a unique URL for each different language is a straightforward solution, but has flaws. First, someone must craft a version of the content page in each possible language. The straightforward approach typically involves generating a master version of the content page in one language (e.g., English) and then translating the master version into all of the target languages. Given the number of languages that exist and the complexity of accurate translation of documents, this is by no means a simple task.
Second, when the content on the master version of the content page changes, the content on each of the translated versions must be changed to match. Again, given the number of languages and the complexity of accurate translation, this can be costly.
Third, a file naming convention, consistent across the entire network, is required. The user must know this naming convention, and must modify the URL of the content page to reflect the desired language. Conceivably, the task of modifying the URL can be shifted to the browser, but then the browser must be given specialized knowledge to know when not to modify a URL (e.g., when the user wishes to view a content page in a language other than the default). If the content provider does not conform to the file naming convention, then the user will not be able to access the content. In addition, if the content provider does not provide the content page in the language specified by the user, the user will be told that the content page does not exist, when it might exist in another language.
Accordingly, a need remains for a way to identify a user's preferred language without having to manually set a preferred language in a browser on a computer, and without the user having to specify language-specific content pages, to address these and other problems associated with the prior art.